Method and Apparatus for Enhanced Internet Telephony 

Background of the Invention 

Today, most common residential broadband deployments are delivered via either 
cable or DSL modem. Such broadband deployment typically provides customers with a 
single Ethernet port that grants one public IP address to a single computer device. Given 
this situation, customers are restricted to using only one computer, and must purchase a 
router if they desire to share the broadband connection to access, for example, the 
Internet between more than one of the customer's computer devices. 

To transport media and telephone signaling, customers commonly use a Multi 
Media Terminal Adapter (MTA) coupled between their source device (e.g., a computer or 
telephone) and their broadband connection. One example of a common Media Terminal 
Adapter is the Cisco ATA 186 Analog to Telephone Adapter (ATA) manufactured by 
Cisco Systems, Inc. of San Jose California. In the case of Internet telephony, the Media 
Terminal Adapter operates as a handset to Ethernet adapter that converts traditional 
telephone analog signals into Internet packets. The packets are then sent using, for 
example, a standard protocol such as Session Initiation Protocol (SIP) on route towards 
their destination. 

Figure 1 is a schematic representation of an example user Internet Telephony 
environment. In Figure 1, a cable modem 10 provides access to the Internet 20. In the 
Figure 1 example, the user employs an intermediate communication point, e.g., router 30 
to provide multiple devices access to the Internet 20. The router 30 assigns respective 
private dynamic IP addresses to the Media Terminal Adapter 40 and to the computer 50. 
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As shown in the Figure 1 example, the Media Terminal Adapter 40 is coupled to a 
common telephone handset 60. The Media Terminal Adapter 40 receives signals from 
the handset 60, creates packets and sends data packets to the Router 30, which in turn 
sends them to the cable modem 10 and eventually to the Internet 20. 

A major drawbacks of the above typical environment is the difficulty in 
accommodating the Network Address Translation (NAT) that is typically implemented 
by the router 30. As is commonly understood, a Dynamic Host Computer Protocol server 
running on the router 30 assigns private dynamic IP addresses to the Media Terminal 
Adapter 40 and computer 50; thus effecting Network Address Translation (NAT). 

When a user wishes to initiate a call and activates the telephone handset 60, the 
handset sends signals to the Media Terminal Adapter 40. The Media Terminal Adapter 
40 then begins the communication/registration process with an Internet telephone service 
provider. The communication between the Media Terminal Adapter 40 and a server of 
the Internet telephone service provider employs a standard protocol such as Session 
Initiation Protocol. But, the router 30 performs the Network Address Translation on a 
timed basis. As is commonly known, typical routers used in home environments assign 
private IP addresses to devices connected to the router. But, those addresses are valid 
only for a limited time. Thus, after the limited time expires, the private address is no 
longer assigned to a given device, such as the Media Terminal Adapter 40. As a result, 
the SIP messages sent from Internet telephone service provider's server are not passed by 
the router 30 to the Media Terminal Adapter 40. Consequently, the Media Terminal 
Adapter 40 can send SIP messages, but is not able to receive packets from the Internet 
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telephone service provider's server due to the router 30 losing the originating outbound 
port and making communication to an MTA located behind a router impossible. 

Figure 2 is a schematic representation of an example environment that addresses 
the issue of router 30 losing an outbound port during an Internet telephone connection. In 
the Figure 2 example, at the Internet telephone service provider a destination, e.g., a pre- 
proxy server 70 receives messages from the router 30. Pre-proxy server 70 records the 
private IP address of the Media Terminal Adapter 40 during, for example, the SIP 
registration process. It also records the network address translation communication port 
assigned by the router 30 to the Media Terminal Adapter 40 to and from which it will 
send and receive messages, such as SIP messages. Upon registration, the Media 
Terminal Adapter 40 passes fields used to communicate with the pre-proxy server 70. 
Examples of fields that can be passed include, for example, the private IP address of the 
Media Terminal Adapter 40, the public IP address of the router 30, and port information. 
After the pre-proxy server 70 receives the information from the Media Terminal Adapter 
40, the pre-proxy server 70 periodically sends, for example, blank UDP messages to the 
Media Terminal Adapter 40, which contain the same destination and source address as a 
typical SIP message would have. Other messages could be use in stead of the UDP 
message. The message used should prompt the Media Terminal Adapter 40 to send a 
response to the pre-proxy server70. The pre-proxy server 70 sends, for example, the 
UDP message to the router 30 using the public IP address of the router 30 and the port 
information received in the message from the router 30. The pre-proxy server 70 sends, 
for example, the UDP within the limited time that the router 30 maintains that private 
address assigned to the Media Terminal Adapter. The router 30 accordingly routs the 
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message to the destination designated in the message from the pre-proxy server 70. The 
pre-proxy server 70 also maintains the private and public IP addresses of the MTA and 
rewrites the headers in the actual SIP messages based on this information. 

The above solution worked, but it did not solve the network address translation 
problem for all routers. For example, some routers would close the outbound port if the 
device behind the router's network address translation did not send an outbound message. 
Thus, there is a need for a solution to the problem, in Internet telephony, of the network 
address translation that a router performs as a part of its intended operation. 

Summary of the Invention 

It is an object of the present invention to provide a method and apparatus for 
enhanced Internet telephony that avoids the above drawbacks. 

It is another object of the present invention to provide a method and apparatus for 
enhanced Internet telephony that allows the use of Session Initiated Protocol technology. 

It is a further object of the present invention to provide a method and apparatus 
for enhanced Internet telephony that allows the use of Session Initiated Protocol 
technology within environments employing network address translation. 

It is still another object of the present invention to provide a method and apparatus 
for enhanced Internet telephony that allows the use of Session Initiated Protocol 
technology with routers employing network address translation. 

To achieve the above and other object, the present invention provides a method 
for providing enhanced Internet telephony that includes receiving a message from a 
source at an intermediate point; sending at least a portion of the message from the 
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intermediate point to a destination over the Internet; sending a response to the message 
from the destination to the intermediate point over the Internet; sending the response 
from the intermediate point to the source; repeatedly sending other messages from the 
destination over the Internet to the intermediate point; sending at least a portion of 
corresponding ones of the other messages from the intermediate point to the source; and 
sending responses to the portions of the other messages from the source to the 
intermediate point. 

Brief Description of the Drawings 

Figure 1 is a schematic representation of an example user Internet Telephony 
environment. 

Figure 2 is a schematic representation of an example environment intended to 
address the issue of a router losing an outbound port during an Internet telephone 
connection. 

Figure 3 is a schematic representation of an example environment employing the 
present invention. 

Description of the Preferred Embodiments 

Figure 3 is a schematic representation of an example environment employing the 
present invention. In Figure 3, a user initiates a call using a telephone handset 60. As 
described above, the media terminal adapter 40 implements standard signaling between 
itself and an Internet telephony regional data center 80. Once the user has been registered 
and the destination has provided a SIP acknowledgment of the SIP invite sent by the 
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media terminal adapter 40, communication between the caller 60 and a customer in a 
destination area 100 proceeds using, for example, Real-time Transfer Protocol (RTP) 
between the caller and the a customer in the destination area 100 via the Internet 20 and, 
for example, a RTP relay 90 in Internet telephony point-of-presence 1 10 in the 
destination area 100. 

However, with the call set up as described above, the router 30 may close the 
outbound port after a timeout period. As a result, voice data from the customer in the 
destination area 1 10 will not reach the telephone handset 60 behind router 30. To avoid 
the router 30 timing out and closing the outbound port, the present invention causes the 
media terminal adapter 40 to send an outbound message to the Internet telephony 
regional data center 80. One way of accomplishing this is to have the pre-proxy server 
75 periodically send an empty SIP notify message to the media terminal adapter 40. The 
media terminal adapter 40 responds to this notify message in accordance with SIP 
standards by, for example sending an acknowledgement message. The sending of a 
message by the media terminal adapter 40 causes the router 30 to keep the outbound port 
open by, for example restarting the router's timeout period. 

Referring to the exemplary embodiment shown in Figure 3, the Internet telephony 
regional data center 80 has the pre-proxy server 75 separated from the RTP relay 85. 
While this separation is not necessary to the present invention, in some environments is 
allows additional functionality to be more easily added to the pre-proxy server 75. An 
example of such additional functionality is the dynamic allocate allocation of the RTP 
relay 85. The pre-proxy server 75 can allocate the closest RTP relay between the two 
calling parties. That allocation enables the ability to decrease latency and travel time of 
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the RTP stream. Also as shown in Figure 3, with the exemplary embodiment, only SIP 
messages get routed to the Internet telephony regional data center 80. The RTP stream 
need not travel to the data center, and depending upon the location of the caller and the 
destination area 100, can travel within a limited geographic area. For examle, the 
telephone handset could be located in California, and the Internet telephony regional data 
center 80 could be located in New Jersey. If the destination area 100 is also in 
Calrfornia, the Internet telephony point of presence in the destination area 90 would be 
allocated by the pre-proxy server 75 to also be in California. Thus, as noted above, the 
RTP stream would remain in California; tending to reduce to decrease latency and travel 
time of the RTP stream. 

In the above, the pre-proxy server 75 is shown and discussed as a separate 
computer. This is for convenience of discussion, for purposes of practicing the invention, 
it does not need to be separate. Instead, the discussed functions that typically would be 
implemented in a pre-proxy server can be implemented in a computer that is also 
functioning as a server. 
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